Assisted-by: claude-opus-5.5 (Claude Code)

Assisted-by: claude-opus-5.5 (Claude Code)

Assisted-by: claude-opus-5.5 (Claude Code)

Assisted-by: claude-opus-5.5 (Claude Code)

The translator’s major version has to match LLVM’s, and 23.1.2 requires
LLVM 23.1.0 (`BASE_LLVM_VERSION`). The SPIRV-Headers commit it pins,
575b6512, is already contained in spirv-headers 1.4.357.0.

Assisted-by: claude-opus-5.5 (Claude Code)

[Description](https://gitlab.freedesktop.org/karolherbst/mesa-libclc):

> This is a fork of LLVM's libclc applying some fixes of a known good
> state.
>
> […] Its main purpose is to function as a reliable base mesa can use
> and fix issues that won't be addressed upstream. It also functions as
> a version pin, so that unexpected changes upstream won't cause
> regressions as the interface between the OpenCL runtimes using libclc
> and libclc itself is not stable.

Since 26.2.0, Mesa looks for `mesa-libclc.pc` first, and falls back to
upstream’s `libclc.pc` only if it is missing. rusticl warns if it does not
load the fork. The fallback stops working with LLVM 23: libclc 23.1.3
builds one target per configuration (`LIBCLC_TARGETS_TO_BUILD` is gone),
installs `share/clc/<triple>/libclc.{spv,bc}`, and no longer ships
`libclc.pc` or the `spirv{,64}-mesa3d-.spv` files Mesa loads.

The fork builds only these two SPIR-V targets, and installs them to
`/usr/share/mesa-clc/` with `/usr/share/pkgconfig/mesa-libclc.pc`, so
it does not conflict with the libclc package. Model the bee-file on
`libclc.be0` and `lld.be0`.

Tag 22.1.8.3 is based on libclc 22, and the fork’s CI builds it with
clang 22, but `LIBCLC_MIN_LLVM` is 22.1.0, so it is meant to be
buildable with LLVM 23, too. The fork has an `llvm_23` branch, but no
tag for it yet.

Assisted-by: claude-opus-5.5 (Claude Code)

Since 26.2.0, Mesa builds against its fork mesa-libclc, which is now
packaged, and no other bee-file refers to libclc.

Porting libclc to LLVM 23 would also not be a version bump: libclc
23.1.3 builds one target per configuration (`LIBCLC_TARGETS_TO_BUILD`
is gone), so the eleven targets of the recipe would need eleven
configurations, and it no longer ships `libclc.pc`.

Assisted-by: claude-opus-5.5 (Claude Code)

Assisted-by: claude-opus-5.5 (Claude Code)

llvm, clang, compiler-rt, lld and spirv-llvm-translator are built as
separate standalone packages, so each can be fine on its own and still
not fit the others. compiler-rt 22.1.8-0 installed its runtimes to
`/usr/lib/linux`, where clang never looks, and nothing noticed until
`-fsanitize=address` failed to link.

So compile, link and run small programs through every package: the
versions agree (including the libLLVM llvm-spirv links), clang finds its
resource directory and compiler-rt, C and C++ with exceptions, lld also
with ThinLTO, compiler-rt's builtins, ASan, UBSan and TSan catching what
they should, profiling with llvm-profdata and llvm-cov, and OpenCL C to
SPIR-V and back with llvm-spirv.

`--prefix` takes image directories or `.bee.tar.bz2` packages and mounts
them read-only over `/usr` in a user namespace, so packages can be
checked before installing them, without root. clang derives its resource
directory from where its binary is, so compiler-rt has to appear below
the same `/usr`.

ASan and TSan reserve terabytes of address space, which hosts with
`vm.overcommit_memory=2`, like the MXQ nodes and servers, refuse. There they
are only linked, and that is reported as a warning.

On machdoch, with the installed LLVM 22.1.8 (lld not installed):

    FAIL  missing: clang 22.1.8, llvm-config 22.1.8, ld.lld missing, llvm-spirv (libLLVM) 22.1
    FAIL  no compiler-rt runtimes in clang's runtime directory (clang -print-runtime-dir: (runtime dir is not present))
    OK    C
    OK    C++ with exceptions
    […]
    FAIL  ASan: clang failed: /usr/bin/ld: cannot find /usr/lib/clang/22/lib/x86_64-unknown-linux-gnu/libclang_rt.asan_static.a: No such file or directory

and with the 23.1.3 packages of this branch:

    $ TMPDIR=/dev/shm scripts/smoke-tests/llvm-smoke-test --prefix …/llvm-23.1.3-0.x86_64.bee.tar.bz2 \
          --prefix …/clang-23.1.3-0.x86_64.bee.tar.bz2 --prefix …/compiler-rt-23.1.3-0.x86_64.bee.tar.bz2 \
          --prefix …/lld-23.1.3-0.x86_64.bee.tar.bz2 --prefix …/spirv-llvm-translator-23.1.2-0.x86_64.bee.tar.bz2
    OK    clang 23.1.3, llvm-config 23.1.3, ld.lld 23.1.3, llvm-spirv (libLLVM) 23.1
    OK    runtime directory /usr/lib/clang/23/lib/linux holds 76 compiler-rt files
    OK    C
    OK    C++ with exceptions
    OK    lld links and runs, .comment names LLD 23
    OK    ThinLTO with lld
    OK    compiler-rt builtins (--rtlib=compiler-rt)
    OK    ASan reports heap-buffer-overflow
    OK    UBSan reports signed integer overflow
    OK    TSan reports data race
    OK    profiling and coverage: compiler-rt profile, llvm-profdata, llvm-cov
    OK    OpenCL C to SPIR-V and back with llvm-spirv, spirv-val accepts it
    PASS (0 failed, 0 warned)

Assisted-by: claude-opus-5.5 (Claude Code)

A version bump of llvm, clang, spirv-llvm-translator or mesa-libclc can
break a Mesa driver without breaking mesalib's build. So check what a
desktop or compute user hits: every Mesa library resolves its shared
libraries; OpenGL ES with llvmpipe and with the hardware driver, each
drawing a shaded triangle and comparing the pixels, so llvmpipe's LLVM
JIT compiles and runs a shader; GLX on an Xvfb of its own; a device on
every GPU of each Mesa Vulkan driver; and an OpenCL kernel calling
libclc builtins on every rusticl device, warning when rusticl does not
find Mesa's libclc fork.

Vulkan and OpenCL go through ctypes, as hosts like machdoch have neither
the Vulkan loader nor its headers: the Vulkan driver is asked for its
entry points directly, through the interface the loader itself uses.
EGL, Vulkan and OpenCL are restricted to Mesa's own vendor files, so
NVIDIA's proprietary driver, where installed, is not what gets tested.
OpenCL loads `/usr/lib/libOpenCL.so.1` by path: the /pkg python wrapper
puts `/pkg/cuda-12.8.1-0/lib` on the library path on machdoch, and the
Khronos loader there found no platform:

    FAIL  OpenCL: no OpenCL platform

`--prefix` works like llvm-smoke-test's, over `/usr` and `/etc`.

On machdoch (Intel CometLake GT2), with the installed mesalib 26.2.2 and
upstream libclc 22.1.8, OpenCL is broken:

    WARN  OpenCL: rusticl uses upstream libclc, not Mesa's fork (install mesa-libclc)
    FAIL  OpenCL Mesa Intel(R) UHD Graphics (CML GT2) (OpenCL 3.1): build failed: Internal compilation error: nir_shader not fully linked
    FAIL  OpenCL llvmpipe (LLVM 22.1.8, 256 bits) (OpenCL 3.1): build failed: Internal compilation error: nir_shader not fully linked

and with the packages of this branch everything passes:

    $ TMPDIR=/dev/shm scripts/smoke-tests/mesa-smoke-test --prefix …/llvm-23.1.3-0.x86_64.bee.tar.bz2 \
          --prefix …/clang-23.1.3-0.x86_64.bee.tar.bz2 --prefix …/spirv-llvm-translator-23.1.2-0.x86_64.bee.tar.bz2 \
          --prefix …/mesa-libclc-22.1.8.3-0.x86_64.bee.tar.bz2 --prefix …/mesalib-26.2.4-0.x86_64.bee.tar.bz2
    OK    7 Mesa libraries resolve their shared libraries, using libLLVM.so.23.1, libLLVMSPIRVLib.so.23.1, libclang-cpp.so.23.1
    OK    mesa-libclc provides its SPIR-V libraries in /usr/share/mesa-clc
    OK    OpenGL ES (software) draws a shaded triangle: llvmpipe (LLVM 23.1.3, 256 bits), OpenGL ES 3.2 Mesa 26.2.4
    OK    OpenGL ES (hardware) draws a shaded triangle: Mesa Intel(R) UHD Graphics (CML GT2), OpenGL ES 3.2 Mesa 26.2.4
    OK    GLX on Xvfb: llvmpipe (LLVM 23.1.3, 256 bits), 4.6 (Core Profile) Mesa 26.2.4
    OK    Vulkan libvulkan_intel.so: Intel(R) UHD Graphics (CML GT2), Intel open-source Mesa driver Mesa 26.2.4, Vulkan 1.4.354, device created
    OK    Vulkan libvulkan_radeon.so: loads, drives no GPU of this host
    OK    OpenCL Mesa Intel(R) UHD Graphics (CML GT2) (OpenCL 3.1) runs a kernel calling libclc builtins
    OK    OpenCL llvmpipe (LLVM 23.1.3, 256 bits) (OpenCL 3.1) runs a kernel calling libclc builtins
    PASS (0 failed, 0 warned)

Assisted-by: claude-opus-5.5 (Claude Code)

On a host with two GPUs, the hardware OpenGL ES check draws only on the one
EGL’s surfaceless platform picks by default. On maleficent that is the Intel
GPU, so radeonsi goes unchecked unless the caller knows to set DRI_PRIME=1:

    $ ./scripts/smoke-tests/mesa-smoke-test
    OK    OpenGL ES (software) draws a shaded triangle: llvmpipe (LLVM 23.1.3, 256 bits), OpenGL ES 3.2 Mesa 26.2.4
    OK    OpenGL ES (hardware) draws a shaded triangle: Mesa Intel(R) HD Graphics 630 (KBL GT2), OpenGL ES 3.2 Mesa 26.2.4
    $ DRI_PRIME=1 ./scripts/smoke-tests/mesa-smoke-test
    OK    OpenGL ES (software) draws a shaded triangle: llvmpipe (LLVM 23.1.3, 256 bits), OpenGL ES 3.2 Mesa 26.2.4
    OK    OpenGL ES (hardware) draws a shaded triangle: AMD Radeon Pro WX 5100 Graphics (radeonsi, polaris10, ACO, DRM 3.64, 6.18.51.mx64.498), OpenGL ES 3.2 Mesa 26.2.4

So list the devices with EGL_EXT_device_enumeration and draw on each through
EGL_EXT_platform_device, as the Vulkan and OpenCL checks already do for their
devices. Mesa’s software device replaces LIBGL_ALWAYS_SOFTWARE for llvmpipe,
and each GPU is reported with its render node.

A GPU that cannot be set up (no display, config or context) is still only a
warning, as Mesa need not have a driver for it, for example for an NVIDIA GPU
on its proprietary driver. Once the context is current, a failure on a GPU
(shader compilation, drawing, wrong pixels) now fails the run instead of
warning, as it is the driver that is broken then.

Assisted-by: claude-opus-5.5 (Claude Code)